Modern semiconductor chips have a wealth of embedded logic for various purposes. Most embedded logic is for IC Test and for IC Debug. There is also logic that is used for process monitoring, yield monitoring, environment monitoring, fault tolerance, and functional configuration. Since there are many purposes for the embedded logic and there has been no standard name established, herein the embedded logic will be generically referred to as “instruments.” Some examples of instrument functions include setting an operating frequency, adjusting power consumption, setting the size of the operating memory, selecting the type of data bus (PCIe, Xaui, etc.), turning data encryption on and off, setting the drive strength of the pins, tuning the chip for its environment (adjusting the voltage and clock frequency to fit the board that the chip is installed within) and so on.
Typically, instruments are involved in some way with embedded configuration and measurement. Some instruments may be intended for use at several levels of an IC lifecycle and by organizations other than the IC provider. These instruments may be referred to as “public” instruments. For example, a public instrument may be intended for use by the IC designer during evaluation and characterization, by the IC manufacturer during test, and by the IC integrator during board test and system development and tuning.
However, another class of instruments may be intended to be used only by a limited group of entities for specific purposes. These instruments may be referred to as “private,” “restricted,” or “proprietary” instruments. As an example, a private instrument may be intended for use only by the IC designer during characterization or only by the IC manufacturer for test purposes.
Some private instruments may be considered destructive. An example is a fuse block that controls power-gating or memory self-repair and, if activated, would result in a processor core being shut off or a memory being remapped to include bad rows and columns. Preferably, no entity outside of a limited group should have access to a private instrument or even know of the existence of a private instrument.
The IEEE 1149.1 Standard
In the early 1990s, the IEEE 1149.1 Boundary Scan Standard was ratified to solve the problem of not having access to the chip-to-board connections involving surface mount chips. 1149.1, also known as JTAG for the Joint Test Action Group that developed it, is a board test standard that accesses an embedded set of serial scan path registers designed into the chip. When the chip is on a board, the registers enable a board test function.
The 1149.1 standard defined three main items: the Test Access Port (TAP), the TAP controller, and the Boundary Scan Register. The TAP defines four signals which must exist on the chip package. The TAP Controller includes an Instruction Register, a Bypass Register, and a finite state machine (FSM) that dictates the sequence and event-order of operations conducted by the various registers. The Boundary Scan Register is a register associated with the chip Input, Output, and Bidirectional signals. The Boundary Scan Register may sample or over-drive those signals, allowing those signals to be verified when the chip is integrated onto a board.
Since there are different test requirements and different numbers of pins on different chips in the marketplace, a later revision of 1149.1 added a description language, the Boundary Scan Description Language (BDSL), to provide a standard method to document the implemented architecture and the collection of supported features, or instructions, supported by any chip-specific 1149.1 design.
Soon after 1149.1's ratification, acceptance, and use as a board test standard, chip designers began using the JTAG TAP and TAP Controller as an IC test or IC debug controller. There were several drivers that led to this practice: reuse of existing logic and package pins, cost and complexity of developing custom test controllers, availability of software to operate the TAP, and the use of embedded IP Cores that may have previously been chips and had supported a JTAG boundary scan architecture. One of the main drivers was that designers noted the cleverness and simplicity of the 1149.1 TAP Controller and that it could be used to operate inside-the-chip features and functions, either by adding instructions to the JTAG Instruction Register which directly created control signals that were asserted as long as the instruction encoding was present, or by adding and using one or more Test Data Registers (TDRs) that would allow serial data to be delivered and extracted from embedded functions.
A TDR is a JTAG register that includes a serial scan path made of bit-cells. This scan path may also be referred to as a “scan pathway,” a “scan chain,” or a “scan register.” A bit-cell comprises Shift storage element and optionally an Update storage element. The value stored in the Shift element may be stored in the Update element while the Shift element continues to operate.
In many cases, the logic function to be accessed by the JTAG logic would not be a perfect fit for JTAG control. The exact implementation would be a mixture between logic that observed the letter of the 1149.1 Standard and what could be viewed as a custom ad hoc logic solution. In addition, the IEEE 1500 Core Test Standard and the IEEE 5001 Nexus Debug Port Standard were developed. These standards officially used the 1149.1 defined TAP and TAP Controller as the ideal controller.
The practice of using the 1149.1 TAP and TAP Controller became so prevalent that this alternate use of the 1149.1 pins and control structure began to result in problematic operation of the 1149.1 logic for board test, its intended purpose. The main problems were in expanding the instruction register. The instruction register was normally small, with just three to five bits which could represent between eight up to thirty-two instructions. Attempting to describe items such as LBIST (Logic Built-In Self-Test) or MBIST (Memory Built-In Self-Test), both the signal connection and the functionality, in the BSDL language was something that BSDL was never meant to do.
Some IC devices had multiple hundreds of memories with individual memory BISTs that had multiple configurations. This would result in expanding the 1149.1 Instruction Register to being hundreds to thousands of bits long. Trying to describe the various modes and configurations would create erroneous BSDL. In addition, selecting embedded test by selecting one instruction does not provide flexible scheduling. When board test organizations would get the chip and the BSDL and put this information into standard 3rd-party tools, the BSDL would not be usable. Incorporating tens of chips on a board or in a system in a daisy-chain architecture would result in a concatenated set of JTAG Instruction Registers that exceeded the capabilities of simple board testers.
The IEEE 1687 Standard
Because of the growth in the use of embedded logic for IC test, IC debug, environmental monitoring (temperature, voltage, frequency), configuration (bus selection, power domains, clock domains), and self-repair (fuses), development of a new proposed IEEE standard, IEEE P1687, began. P1687 would specifically address the connection of embedded inside-the-chip logic to the 1149.1 TAP and TAP Controller. The preferred IEEE P1687 implementation would result in an embedded access network that could be designed without overloading the 1149.1 Instruction Register and without requiring excess content to be added to the BSDL file. The P1687 proposed standard currently solves these problems by recommending that one or just a few instructions are added to the 1149.1 Instruction Register and that these instructions connect a special TDR into the serial scan path between the TDI and TDO chip signals. The special TDR is known as a Gateway Register or Gateway TDR.
The P1687 preferred architecture would use a Gateway Register that is made from special “gateway” bit-cells known as Segment-Insertion-Bits (SIBs). A SIB is a special bit-cell that allows scan path segments to be inserted into and removed from the scan path based on the data shifted into the SIB and then latched by an update operation. A hierarchical scan path may be created and/or selected by inserting scan path segments. Under the previous 1149.1 standard, a control instruction selected the scan path registers.
This type of architecture allows the 1687 network itself to shrink and grow, based on the data in the network, whenever the 1149.1 FSM passes through the Update-DR state—as opposed to the 1149.1 method of installing a new instruction in the Instruction Register and passing through the Update-IR state.
The proposed 1687 Standard then has several main differences from 1149.1. First, the 1687 network allows dynamic length-changing scan paths while a single instruction resides in the 1149.1 Instruction Register, whereas the 1149.1 Standard requires a fixed-known-and-documented length scan path for each instruction. Second, all 1687 network actions occur on the Data-Register (DR) side of the 1149.1 FSM, whereas the 1149.1 Standard changes the 1149.1 active register based on changing instructions on the Instruction-Register (IR) side of the 1149.1 FSM. Third, the 1687 architecture will be described using a hardware description language (currently known as ICL, for Instrument-Connectivity-Language) associated directly with the 1687 Standard, as opposed to the 1149.1 BSDL—the only items described in the 1149.1 BSDL are the instructions that select 1687 Gateway Registers.
One of the main efficiencies of the 1687 Standard is that the 1149.1 portion of the architecture returns to the simplified board test configuration with a small Instruction Register and a small addition of information to the BSDL description. Another efficiency of the 1687 Standard is that a wealth of embedded content, known generically as instruments, may be accessed and operated with a dynamic data-driven system that allows adding and subtracting scan path segments by using the SIB concept.
Instrument Protection
In the past, each classification or grouping of instruments, such as test, debug, and yield, had its own custom interface and access mechanism depending on where in the IC lifecycle it was to be accessed. The test logic such as Manufacturing Scan, Logic BIST, Memory BIST, and other similar features has traditionally been accessed through borrowed functional pins and through wide, parallel interfaces that use lots of pins to reduce test time, as more tester channels operating in parallel reduces test time and cost. Debug Logic such as trace buffers, traffic monitors, and hardware assertions have traditionally been accessed through a small dedicated port that exists at both the ATE testing and when the chip is integrated on a board. Alternately, Debug Logic may time-share a functional interface such as a data bus. Yield monitors have generally been used during wafer processing or at wafer probe to assess the frequency, temperature, and voltage performance of the silicon-using items such as ring-oscillators and voltage-controlled-oscillators. Yield monitors are generally accessed through test pads.
Because of recent changes in silicon manufacturing to achieve sub-100 nanometer geometries, to truly assess silicon after manufacturing and during board integration many of these instruments may need to work together. This creates a need for same or a standard access mechanism for all of the instruments. By placing all of these instruments on the same access mechanism, the instruments may be used in conjunction with each other, test scheduling of any grouping of embedded instruments may be accommodated, power consumption during instrument use may be flexibly adjusted, power domains and clock domains where logic is totally quiescent when not being used may be accommodated, and the access cost in data bandwidth and access time may be flexibly adjusted as needed.
However, instrument protection is an issue with the current 1149.1 JTAG Method and the proposed 1687 Standard. The disadvantage to having all instruments within an IC on one access mechanism or access network is that a user of the access network now has access to all instruments and the user knows that all instruments, public or private, may be accessed and operated in a similar manner. For example, all IEEE 1687 Standard-based instruments may be written-to or operated-by serially shifting from the IC's TDI pin to place assertion bits into Test Data Registers (TDRs) and then conducting an Update-DR operation. All instruments may be read-from for state or status by conducting a Capture-DR and then serially shifting the TDRs out through the IC's TDO pin.
On one hand, there are benefits to documenting a 1687 network and instruments. The documentation provides ease of development, modular plug and play, the standardization to enable software automation for vector generation and vector reuse. The documentation also makes it easier for the different organizations such as design verification, IC test, and board test to understand and operate the instruments.
However, on the other hand, if a 1687 network is documented, all of the embedded content is visible to anyone that knows about the JTAG port and the 1687 network. An IC developer may wish to make private instruments known only to the IC developer's company and invisible to the public. For example, some instruments may be used by the IC developer to develop ATE-based tests for IC test and data-collection for yield-monitoring. For efficiency, these instruments are included in the 1687 network and are operated by the test and failure-analysis portions of the IC provider's company. When the IC is shipped to a customer that will integrate the IC onto the board, the private instrument's documentation may be removed. However, the bits in the scan path that feed the instrument will still be in the 1687 network.
The current practice for including private instruments in both 1149.1 and 1687 networks is to simply not document the existence of the instrument in the Hardware Description Language file publicly delivered with the chip. Alternately, the private instrument bits may be documented only as private bits. In either case, the function of the instrument is undocumented. However, existence of the instrument bits is apparent, either because the absence of documentation is conspicuous or because the bits are expressly documented as private. An individual may further investigate the bits with undocumented functions to discover the private instruments.
For private instructions for the 1149.1 standard, curious and malicious individuals and organizations have shifted-in values that represent the opcodes for private instructions and have attempted to figure out what the private instructions are for, even if the instructions are destructive. A similar course of events is expected for 1687 networks—undefined bits will be explored by curious and malicious individuals.
For 1149.1 networks, the documentation typically explains the size in bits of the 1149.1 instruction register, since instructions may be scanned in through the TDI pins and scanned out through the TDO pins. For example, a 5-bit instruction register may receive 32 possible instruction encodings. If only 16 instructions are documented in the BSDL file, then it is apparent that there are 16 encodings that may perform undocumented instructions. To investigate these undocumented private instructions, the encodings not documented in the BSDL may be shifted into the TDI and an Update-IR operation may be conducted. It is therefore not difficult to investigate these private instructions, as curious and malicious individuals have attempted to do.
Similarly, with networks based on the IEEE 1687 standard, a SIB that provides access to a scan path may be viewed as an instruction register. The scan paths may represent TDRs that may include other SIBs, or may be used as Instrument Interface Registers (registers that provide signals to and from instruments). When the function of a TDR or a SIB is left undocumented, the lack of documentation is conspicuous and invites further investigation.
For example, a 16-bit TDR may contain 16 SIBs that may open 16 different scan path segments. Six of those SIBs may be left undocumented or may be labeled as private. Each of those SIBs may open up individual scan paths that contain 32-bit registers used as interfaces to private instruments. Those 6 instruments are considered private, and they and their access mechanisms have been left undocumented.
However, SIBs are operated by serially shifting an assertion value, such as a logical 1, into the Shift cell using several Shift-DR operations. When the assertion value is shifted into the Shift cell, an Update-DR operation is conducted to move the logical 1 assertion value into position. The Update-DR operation opens the added scan path and provides access to the private 32-bit instrument interface. Curious or malicious individuals may then investigate what behaviors and operations occur when individual bits or certain encodings are installed into the 32-bit instrument interface.
In conclusion, an effort to not publicly document SIBs and hierarchical scan path registers is insufficient to prevent access to private instruments by unauthorized individuals and organizations. The lack of documentation may make those instruments distinguishable from the rest of the network. For example, the private instruments may appear as unused bits in a scan path with no associated documentation, or as bits documented as private bits given a “must always be a logical 0” directive. In either case, the absence of documentation is conspicuous and will attract the attention of an individual attempting to discover private instruments.
Therefore, absence of documentation may not be enough to keep an instrument private. There is a need to effectively hide the existence of private instruments from a curious individual or organization.